# 테스트 자동화 (Test Automation)

## 1. 개요
테스트 자동화란 소프트웨어 테스트 프로세스를 사람이 직접 수행하는 대신, 특정한 도구와 스크립트를 사용하여 자동으로 실행하고 검증하는 기술적 방법론을 의미한다.

수동 테스트(Manual Testing)가 테스터의 직관과 경험을 바탕으로 탐색적 테스트를 수행하는 데 강점이 있다면, 테스트 자동화는 반복적이고 정형화된 검증 과정을 빠르게 처리하여 휴먼 에러를 줄이고 효율성을 극대화하는 데 목적이 있다. 자동화를 도입함으로써 얻을 수 있는 주요 기대 효과는 다음과 같다.

*   **실행 속도 향상:** 수동으로 수 시간~수 일이 걸리는 회귀 테스트를 수 분 내로 단축할 수 있다.
*   **일관성 확보:** 동일한 입력 값에 대해 항상 동일한 검증 절차를 수행하므로 테스트 결과의 객관성이 보장된다.
*   **리소스 최적화:** 단순 반복 작업에서 해방된 QA 엔지니어가 고차원적인 탐색적 테스트나 설계 검토에 집중할 수 있다.
*   **빠른 피드백 루프:** 개발 단계에서 즉각적인 테스트 실행이 가능하여 결함 발견 및 수정 비용을 낮출 수 있다.

## 2. 테스트 자동화 피라미드
테스트 자동화 피라미드는 효율적인 테스트 전략을 위해 각 테스트 레벨의 비중을 어떻게 설정해야 하는지를 보여주는 모델이다. 하위 계층일수록 실행 속도가 빠르고 비용이 저렴하며, 상위 계층으로 갈수록 실행 속도가 느리고 유지보수 비용이 증가한다.

**[테스트 피라미드 개념도]**
```text
      / \          <- UI/E2E 테스트 (최소 비중, 느린 속도, 높은 비용)
     /   \
    /-----\        <- 서비스/API 테스트 (중간 비중, 보통 속도, 보통 비용)
   /       \
  /---------\      <- 단위 테스트 (최대 비중, 빠른 속도, 낮은 비용)
 /___________\
```

| 테스트 레벨 | 목적 | 실행 속도 | 비용/유지보수 | 신뢰도(격리성) | 권장 비중 |
| :--- | :--- | :--- | :--- | :--- | :--- |
| **단위 테스트 (Unit)** | 개별 함수/메서드의 논리 검증 | 매우 빠름 | 낮음 | 매우 높음 | 가장 높음 |
| **서비스 테스트 (Service/API)** | API 엔드포인트 및 비즈니스 로직 검증 | 보통 | 보통 | 보통 | 중간 |
| **UI/E2E 테스트** | 사용자 관점의 전체 시나리오 검증 | 느림 | 높음 | 낮음 (환경 의존적) | 가장 낮음 |

*   **단위 테스트:** 소스 코드의 가장 작은 단위(함수, 클래스 등)를 독립적으로 테스트한다.
*   **서비스 테스트:** UI 없이 API 레벨에서 비즈니스 요구사항이 올바르게 구현되었는지 검증하며, 통합 테스트의 핵심 영역을 포함한다.
*   **UI/E2E(End-to-End) 테스트:** 실제 사용자 환경과 유사하게 프론트엔드부터 백엔드, DB까지 전체 흐름을 테스트한다.

## 3. 주요 자동화 대상 및 유형
모든 테스트를 자동화하는 것은 불가능하며 비효율적이다. 따라서 자동화 효율이 높은 영역을 우선적으로 선정해야 한다.

### 3.1. 자동화 대상 선정 기준 (Checklist)
어떤 테스트 케이스를 자동화할지 결정할 때 다음 기준을 참고한다.
- [ ] **반복성:** 매 배포마다 반복적으로 수행해야 하는 테스트인가?
- [ ] **결정성:** 입력 값에 따른 기대 결과가 명확하고 일관적인가?
- [ ] **리스크:** 실패했을 때 비즈니스에 치명적인 영향을 주는 핵심 기능인가?
- [ ] **안정성:** UI나 요구사항이 빈번하게 변경되지 않는 안정적인 기능인가?
- [ ] **데이터 복잡도:** 수동으로 준비하기에 데이터 셋이 너무 방대하거나 복잡한가?

### 3.2. 주요 자동화 유형
*   **회귀 테스트 (Regression Testing):** 새로운 기능 추가나 코드 수정 후, 기존에 정상 작동하던 기능들이 여전히 잘 작동하는지 확인하는 테스트다. 반복 횟수가 가장 많으므로 자동화 1순위 대상이다.
*   **API 테스트:** UI가 완성되기 전, 서버의 엔드포인트(Endpoint)가 정의된 명세서대로 응답을 반환하는지 검증한다. UI 테스트보다 빠르고 안정적이다.
*   **성능 및 부하 테스트 (Performance/Load Testing):** 다수의 사용자가 동시에 접속했을 때 시스템의 응답 시간, 처리량, 자원 사용률 등을 측정하여 임계치를 확인한다.
*   **UI/UX 테스트:** 웹이나 앱의 화면 요소가 올바르게 배치되었는지, 사용자 시나리오에 따른 화면 전환이 정상적인지 검증한다.

## 4. 테스트 자동화 프로세스 및 프레임워크
테스트 자동화는 단순한 스크립트 작성을 넘어 체계적인 라이프사이클 관리가 필요하다.

### 4.1. 자동화 라이프사이클
1.  **계획 수립:** 자동화 대상 선정, 도구 결정, 테스트 환경 정의.
2.  **설계 및 스크립트 작성:** 테스트 케이스를 기반으로 자동화 스크립트 구현.
3.  **실행:** 정의된 환경에서 스크립트를 구동하여 테스트 수행.
4.  **결과 분석 및 보고:** Pass/Fail 결과 확인, 실패 원인 분석(로그, 스크린샷), 리포트 생성.
5.  **유지보수:** 요구사항 변경에 따른 스크립트 업데이트.

### 4.2. 스크립트 예시 (Python + Pytest)
본 예시는 BDD(Given-When-Then) 패턴을 적용하여 작성되었습니다.

```python
import requests

def test_get_user_info():
    # 1. Given: 테스트 대상 URL 및 조건 설정
    url = "https://api.example.com/users/1"
    
    # 2. When: API 요청 실행
    response = requests.get(url)
    
    # 3. Then: 기대 결과와 실제 결과 비교 (Assertion)
    assert response.status_code == 200
    assert response.json()['name'] == "홍길동"
```

## 5. 주요 도구 및 기술 스택
프로젝트의 성격(웹, 앱, API)과 팀의 기술 스택에 따라 적절한 도구를 선택해야 한다.

| 도구 | 지원 언어 | 테스트 대상 | 주요 특징 |
| :--- | :--- | :--- | :--- |
| **JUnit / TestNG** | Java | 단위/통합 | 자바 생태계의 표준, 강력한 어노테이션 기반 테스트 |
| **Pytest** | Python | 단위/API/UI | 간결한 문법, 강력한 플러그인 생태계, 범용성 높음 |
| **Cypress** | JavaScript | 웹 UI | 브라우저 내부 실행으로 속도가 빠르고 디버깅이 용이함 |
| **Playwright** | JS, Python, Java | 웹 UI | 멀티 브라우저 지원, Auto-waiting 기능으로 테스트 안정성 향상 |
| **Appium** | 다양한 언어 | 모바일 앱 | iOS/Android 통합 테스트 가능, WebDriver 프로토콜 기반 |
| **Maestro** | YAML | 모바일 앱 | 단순한 YAML 기반 정의, 빠른 실행 속도와 높은 안정성 제공 |

## 6. CI/CD 파이프라인 통합
테스트 자동화의 진정한 가치는 지속적 통합(CI) 및 지속적 배포(CD) 파이프라인에 통합되었을 때 발휘된다.

*   **통합 흐름:** `코드 푸시(Push)` $\rightarrow$ `빌드(Build)` $\rightarrow$ `단위 테스트 실행` $\rightarrow$ `배포(Staging 환경)` $\rightarrow$ `서비스/E2E 테스트 실행` $\rightarrow$ `최종 승인` $\rightarrow$ `운영 배포(Production)`.
*   **게이트키퍼(Gatekeeper) 역할:** 테스트 자동화 결과가 'Fail'일 경우, 파이프라인을 즉시 중단시켜 결함이 운영 환경으로 유입되는 것을 원천 차단한다.
*   **피드백 자동화:** 테스트 실패 시 Slack, Jira, Email 등을 통해 담당 개발자에게 즉시 알림을 전송하여 수정 시간을 단축한다.
*   **도구:** Jenkins, GitHub Actions, GitLab CI, CircleCI 등이 주로 사용된다.

## 7. 테스트 데이터 관리 전략
자동화 테스트의 안정성은 데이터의 일관성에 달려 있다. 데이터 오염을 방지하기 위한 전략은 다음과 같다.

*   **독립적 데이터 생성 (Setup/Teardown):** 테스트 시작 전 필요한 데이터를 생성하고, 종료 후 삭제하여 테스트 간 간섭을 제거한다.
*   **데이터베이스 스냅샷:** 테스트 시작 전 DB를 특정 시점으로 복구(Restore)하여 항상 동일한 초기 상태에서 시작한다.
*   **모킹(Mocking) 및 스터빙(Stubbing):** 외부 API나 DB 등 의존성이 있는 시스템을 가짜 객체(Mock)로 대체하여 네트워크 지연이나 외부 환경 변화에 영향을 받지 않게 한다.
*   **전용 테스트 데이터 셋:** 환경별(Dev, QA, Staging)로 구분된 정적 데이터 셋을 관리한다.

## 8. 도입 시 고려사항 및 한계

### 8.1. 유지보수 비용 (Maintenance Cost)
자동화 스크립트는 UI 변경이나 비즈니스 로직 수정 시 함께 업데이트되어야 한다. 특히 UI 테스트의 경우, 단순한 CSS 클래스 변경만으로도 테스트가 실패하는 '취약한 테스트(Flaky Test)' 문제가 발생할 수 있다. 이를 해결하기 위해 **페이지 오브젝트 모델(Page Object Model, POM)**과 같은 디자인 패턴을 적용하여 UI 요소와 테스트 로직을 분리해야 한다.

### 8.2. 자동화의 한계
*   **탐색적 테스트의 부재:** 자동화는 '정해진 시나리오'만 검증한다. 예상치 못한 엣지 케이스나 사용자 경험(UX)의 불편함은 사람이 직접 확인해야 한다.
*   **초기 구축 비용:** 스크립트 작성 및 환경 구축에 상당한 시간과 인력이 소요된다.

### 8.3. ROI(투자 대비 효과) 측정 지표
*   **테스트 실행 시간 단축률:** ((수동 테스트 시간 - 자동화 테스트 시간) / 수동 테스트 시간) * 100
*   **결함 발견 시점:** 개발 초기 단계(Shift-Left)에서 발견된 결함 수의 증가 추이.
*   **테스트 커버리지(Test Coverage):** 전체 요구사항 대비 자동화된 테스트 케이스의 비율.
*   **회귀 테스트 주기:** 배포 전 전체 회귀 테스트에 소요되는 시간의 변화.

## 9. 관련 용어
*   **Shift-Left:** 테스트 단계를 개발 프로세스의 앞부분(왼쪽)으로 이동시켜 결함을 조기에 발견하고 수정 비용을 줄이는 전략.
*   **Flaky Test:** 동일한 코드임에도 불구하고 실행 환경이나 타이밍에 따라 결과가 성공과 실패를 반복하는 불안정한 테스트.
*   **POM (Page Object Model):** 웹 페이지의 UI 요소와 해당 요소를 제어하는 로직을 별도의 클래스로 분리하여 유지보수성을 높이는 디자인 패턴.
*   **BDD (Behavior Driven Development):** 사용자 행동 중심의 개발 방식으로, 'Given-When-Then' 구조를 통해 기획자, 개발자, 테스터가 동일한 이해관계를 갖도록 하는 방법론.
*   **ISTQB (International Software Testing Qualifications Board):** 국제 소프트웨어 테스트 자격 인증 위원회로, 글로벌 표준 테스트 가이드라인을 제공한다.